本日承襲自昨日的文章，所以直接從「作法」的章節繼續講述。
預期行為就是指當我們透過「重現步驟」操作時，我們預想中理應該出現的行為、結果、狀態。
預期行為在於讓開發團隊暸解我們心中認為正常的認知是否與當初產品設計時相同，讓兩方在這方面的資訊是對稱的。在產品設計時，難免會有產品的行為與使用者的預期行為不同的情況，使用者會因為這種情況認定是程式發生異常，進而回報。但事實上，程式並沒有問題，只是當初產品設計時在使用者經驗（UX）的決策不夠理想，或是設計概念比較新穎，使用者和市場並還沒被教育過。所以若能知道使用者預期行為，就能避免把時間成本耗費在處理其實不是異常的回報中，而能讓客服先將這部分的回報篩選掉，讓開發團隊得以專注在真正的異常回報中。
實際行為就是指當我們透過「重現步驟」操作時，實際發生行為的描述，通常也就是對異常的描述。
與預期行為同理，這部分的描述能讓開發團隊暸解我們實際遇到的情況，並透過是否與產品設計相符或相異去進一步判斷發生什麼事。排除設計和使用這預期行為的非異常回報，這部分的資訊就是讓開發團隊搭配重現步驟去分析重要描述。與「問題描述」相似，但如同「問題描述」是「標題」的進一步說明，那「實際行為」就是「問題描述」中，關於異常更詳細的描述。
影像的部分是比較選擇性提供的資訊，包括螢幕截圖和操作的實際錄影。有時候這些資訊會直接在其他章節中提供，像是在重現步驟中，每步驟提供一個螢幕截圖、或是在實際行為中，把看到的情況截圖附上。
影像是更真實的記錄，讓開發團隊若是對我們所描述的文字仍有點困惑時，能透過影像去暸解我們實際想表達的。或是如重現步驟中所說，透過畫面可以補足我們沒有意識到是有用處的資訊，但對開發者團隊來說是關鍵的細節。
環境的部分是指程式運作的環境，舉凡作業系統、瀏覽器、相依函示庫等等，各家產品和版本都可能會影響程式的運作。這部分亦是很著要的資訊，其重要性不亞於版本、重現步驟等描述。
環境資訊讓開發團隊在進行判斷時，可以先暸解異常會不會有可能只是環境造成的落差，而不是程式核心邏輯的錯誤，如此才能朝正確的方向進行異常排除。程式在開發時，很難保證在所有環境都能行為一致，尤其是網頁程式，在常見的四大瀏覽器（Chrome, Firefox, Safari, IE）的顯示可能都有細節的差異，甚至在同一種瀏覽器，在不同版本都會有不同。像是 IE 系列，在 6 ~ 11 的差異都滿大的。
有時候程式可能會被執行的環境太多種，開發團隊沒有太多成本一一測試與驗證，或是為了支援太舊環境的成本太高，所以決定不再適用。但是就算開發團隊有在產品某處或者安裝程式提及，使用者不一定會知道這些訊息（忽略說明訊息），導致誤以為程式出了異常，但事實上只是該環境已經不被支援，或是不在驗證過的支援清單中。若有此資訊，就可以在客服階段就先為使用者解惑，減少處理時間與成本。
若是該環境是在程式認定的支援清單中，開發團隊也能搭配重現步驟快速了解狀況，並透過交叉比對去判斷是核心邏輯的錯誤，還是環境支援沒有完善。
以下提供比較常見的環境資訊：
在提供這類資訊，除了環境名稱與主要版本號外，建議透過說明或者關於的資訊，取得比較詳細的版本號一併附上，會對開發團隊更有幫助。
這部分又稱最小可重現模型（Minimal reproduction），比較偏向當產品是開發用的函式庫、框架時，會需要使用這個產品的開發者提供，而不是一般使用者。
當我們使用某個函式庫、套件或框架時，若遇到異常，除了上述的資訊外，若能提供程式碼給產品的開發團隊去暸解，一定會更有幫助。但是我們也不能把我們自己產品的程式碼完全給開發團隊，一來可能是會有商業考量，這些程式碼是公司資產，不得任意外洩、二來是開發團隊也沒有時間和義務幫看你的產品的原始碼。這時候就需要針對發生異常的部分，實作最小可實現模型，不包含其他核心邏輯，純粹只有使用他們產品時的程式碼，越簡單且能重現異常越好。
而在實作小可實現模型時，也算是再次確認。我們自己在開發產品時，會由各種邏輯混雜在一起，若是架構沒設計好，很有可能就會互相影響。透過實作最小實現模型，讓我們能夠排除是其他程式碼間接造成異常的可能性，而能聚焦該產品發生異常的原因與位置。
只要是不屬於本章中所提到的任何項目，但認定可能會對開發團隊排除異常有幫助的資訊都可以寫在這部分。
像是這個異常沒辦法百分之百重現，甚至連重現步驟都難以確立，就可以在這邊加註。或是這個功能在以前都沒有發生過異常，是在某個版本後才故障。或是我們認為以我們的專業知識，能夠協助開發團隊排除異常，也可以在這邊寫下我們的看法。諸如此類。
TO BE CONTINUED
本日感想（無關主題）
時光匆匆，聖誕週末就在忙碌中過去，能使用電腦的時間少之又少，只好先欠債了。還好今天睡前總算還是把一篇寫出來，還掉「第四天」的債，接下來就看能在哪天把進度追回囉！也感謝讀者的體諒，祝大家佳節愉快。
iThome鐵人賽
看影片追技術